Using CDI Beans from outside the deployment

For WildFly 8 onwards, it is now possible have classes outside the deployment be picked up as CDI beans. In order for this to work you must add a dependency on the external deployment that your beans are coming from, and make sure the META-INF directory of this deployment is imported, so that your deployment has visibility to the beans.xml file (To import beans from outside the deployment they must be in an archive with a beans.xml file).

There are two ways to do this, either using the MANIFEST.MF or using jboss-deployment-structure.xml.

Using MANIFEST.MF you need to add a Dependencies entry, with meta-inf specified after the entry, e.g.

Dependencies: com.my-cdi-module meta-inf, com.my-other-cdi-module meta-inf

Using jboss-deployment-structure.xml you need to add a dependency entry with meta-inf="import", e.g.

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <dependencies>
            <module name="deployment.d1.jar" meta-inf="import"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

Note that this can be used to create beans from both modules in the modules directory, and from other deployments.

For more information on class loading and adding dependencies to your deployment please see the Class Loading Guide

Suppressing implicit bean archives

CDI  1.1 brings new options to packaging of CDI-enabled applications. In addition to well-known explicit bean archives (basically any archive containing the beans.xml file) the specification introduces implicit bean archives.

An implicit bean archive is any archive that contains one or more classes annotated with a bean defining annotation (scope annotation) or one or more session beans. As a result, the beans.xml file is no longer required for CDI to work in your application.

In an implicit bean archive only those classes that are either annotated with bean defining annotations or are session beans are recognized by CDI as beans (other classes cannot be injected).

This has a side-effect, though. Libraries exist that make use of scope annotation (bean defining annotations) for their own convenience but are not designed to run with CDI support. Guava would be an example of such library. If your application bundles such library it will be recognized as a CDI archive and may fail the deployment.

Fortunately, WildFly makes it possible to suppress implicit bean archives and only enable CDI in archives that bundle the beans.xml file. There are two ways to achieve this:

<jboss xmlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>

/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true)

portable mode

CDI 1.1 clarifies some aspects of how CDI portable extensions work. As a result, some extensions that do not use the API properly (but were tolerated in CDI 1.0 environment) may stop working with CDI 1.1.If this is the case of your application you will see an exception like this:

org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization

Fortunately, there is a non-portable mode available in WildFly which skips some of the API usage checks and therefore allows the legacy extensions to work as before.

Again, there are two ways to enable the non-portable mode:

<jboss xmlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" non-portable-mode="true" />
</jboss>

/subsystem=weld:write-attribute(name=non-portable-mode,value=true)